Networks are based on architectures which are under development. 3GPP is one group which develops networks worldwide and provides standards for communication networks and devices for these networks. Modern real-time application services may be used at present to enable different traditional real services on the mobile phone. These real-time applications services are for example voice over IP communication, such as provided by Skype. These services are in general application layer driven. A 3G network which may be used to connect the mobile devices may remain unaware of the real-time data transmission going on this device and may behave as a typical pipe. This may be due to the following characteristics of such services:
Firstly, the application may decide which protocol to be used for sending the real-time data, on the bearer, for example Real Time Protocol (RTP). Secondly, the application may take care of connection management on the bearer, for example keep alive behaviour.
The core network where a packet data protocol context (PDP context) is set up may remain unaware of the time, when the RTP data is flowing and when the connection management messages, like keep alive behaviour data, is flowing on the same bearer. Hence, during real-time traffic, a network server may not get a chance to invoke the energy conserving procedures defined by 3GPP.
With the advances in the mobile network, a user can have a TV (television) like reception on its mobile phone. These mobile phones or end devices strive hard to conserve its energy while supporting such reception. The modern real-time application services uses application level protocols like RTSP (Real Time Streaming Protocol), XML (eXtended Markup Language), etc, to deliver the connectivity, which may be above the transport and L2 protocols. Even the media (e.g. RTP and media management (like keep-alive) are application level defined.
Modern real time applications on handsets use application layer keep-alive messages to prevent the connections from closure, when traffic is not flowing (e.g. due to silence). For example, 3GPP (3rd Generation Partnership Project) recommends the use of ICE (Interactive Connectivity Establishment) in IMS (IP-Multimedia Subsystem) networks, while, HTTP (Hyper Text Transfer Protocol) Websocket based communications recommends, ping for keep-alive. This creates an issue with the handset in executing the power conservation schemes as the keep-alive and media travel on the same TFT (Traffic Flow Template). In such a case, the end device may remain unaware of the media transmission type and is unable to trigger the standard conservation procedures.
There are known protocols defined for real-time communication for keep-alive behaviour. One of these protocols is for example the mechanism defined in IETF RFC 6223 and IETF RFC 5245, where the STUN keep-alive package (STUN=Session Traversal Utilities for NAT) may be exchanged whenever there is a silence detected. This is to do the nut connections active in case a silence is detected for traffic. In such cases, the TFT (Traffic Flow Template) for keep-alive behaviour and media “be the same”, as the five tuples of TFT are the same. The five tuples of TFT may include source-IP, source-port, destination IP, destination port and transport protocol, such as UDP. Therefore, media and keep-alive parameters may be in this case travelling on the same PDP context, since the TFT are the same in this case. Therefore, the device will not get a chance to invoke energy conservation schemes.
Furthermore, it has to be taken into account the multiple PDP contexts created for a real-time data transmission. Due to guidelines of standardization documents, a lot of bearer may be created on a mobile phone, which may drain out the energy for such a device, even though the device is not having active traffic. In such cases, the policy control framework may comprise a PCRF (Policy and Charging Rule Function) and GGSN (Gateway GPRS Support Node) combination. Such a policy control framework may play a role on when enabling the energy preservation scheme on the mobile phone. This policy may help in saving a high amount of battery life for the mobile device.
3GPP provides mobile network architectures of the third generation with radio access based on UMTS and further optimizations comprising technologies of HSPA. Further evolutions of networks are introduced with 3GPP release 8 TS23.002, which comprises a new type of radio access called LTE (Long Term Evolution). Architectural changes also have been specified for the mobile core network named EPC (Evolved Packet Core) which may connect mobile users apart from LTE via legacy 3GPP radio access or even non-3GPP accesses, such as WLAN.
Multimedia streaming in public land mobile networks (PLMN) may be one focus of 3GPP standardization. The evolved packet core is a part of the core network, which was introduced in 3GPP release 8 and later. However, the EPC also considers earlier 3GPP releases, for example release 4 to 7, where operator managed application is controlled by the IP multimedia subsystem (IMS). The IMS may interact with a policy control function (PCRF) to influence resource allocation for a UMTS bearer service. Examples for multimedia streaming applications are video call and IP-TV. At present the usage of smart phones and tablet PCs simulate a significant increased usage of multimedia streaming applications in PLMNs.
It is known, that applications managed within IMS may control access to resources via a PCRF. However, no mechanisms may be known for non-IMS controlled applications in order to influence resource allocation in PLMN fourth generation networks, such as EPC. From the third generation networks (GPRS) it is known in order to reserve resources for an application, that the client may request per media the setup of a secondary PDP context with the appropriate bit rate. In LTE technology the network may establish a dedicated bearer per media via application function without any involvement of the application client. The request may be mapped by the PCRF to policy rules in order to map media session information to concrete QoS parameters for the bearer service. For example, for streaming communication services like video calls, a QoS class identifier (QCI) of value “2” or of value “4” with guaranteed bit rate service (GBR) may be used. Also for IMS controlled IP-TV the QCI of value “4” may be utilized but dependent on a policy of the operator non-GBR classes could be used, for example dependent on a subscriber profile. Other alternatives are the detection of the application via traffic detection function (TDF), which may utilize deep packet inspection functionality (DPI). The TDF may inform the PCRF about detected applications, then the PCRF may update policies in the gateway and the gateway may for example trigger the establishment of a dedicated bearer.
However, the current streaming service do neither support a SIP based interface to the IMS nor act as IMS application servers supporting an Rx-interface. An Rx-interface is understood as an interface between an AF (Application Function) and a PCRF. It may be diameter based and explained in 3GPP defined in document TS 29.214. At the moment there is no interaction between applications and networks. In case of congestion the rate can not be adapted so far. Thus, at current streaming services are offered via non-GBR bearers and thus can be impacted by high cell load.
There may be a need for mechanisms to manage an increased usage of multimedia streaming applications efficiently.